adaptation of JDK-8 to build with in-tree freetype #4287

judovana · 2025-10-28T13:42:07Z

Hello!

There is openjdk/jdk8u-dev#709 agreed to go to jdk8, so a change in temurin-build is necessary to continue tp support future jdk8/

This is minimalist change, which is allowing to build jdk8 as temurin, but I do not belive it is correct, enough, nor final.

What is supposed to be supported in this script? Older jdk8? Jdk9+10? And so on. If none, maybe whole freetype download and build can be remove? Due to nature of tis commit, the jdk8 build in CI is most liekly going to fail before openjdk/jdk8u-dev#709 is merged and used.

Any guidance or thoughts highly appreciated

karianna · 2025-10-28T21:01:53Z

For completeness it would be good to detect jdk8u_+

judovana · 2025-10-29T11:57:40Z

For completeness it would be good to detect jdk8u_+

You mean to distinguish the freshly released "jdk8 5b3" as it went out 2014 or to distinguish the particular u472 and older x future ones?

karianna · 2025-10-29T19:29:45Z

being able to still support older jdk8 would be useful for completeness.

judovana · 2025-10-30T09:07:09Z

That may be easier then to fully support the custom build of free type. If the tag will be present, which usually is, then it can be decided. If not, the future in-tree approach should take place. Or maybe add switch?

However to fully remove the custom freetype, would simplify the scripts a lot. I'm still just brainstorming. Am not sure which direction to take. Thanx a lot for inputs!

the if is to long, will refactor

judovana · 2025-11-05T11:05:37Z

being able to still support older jdk8 would be useful for completeness.

@karianna WDYT now? It is based on tag, so pretty limited, but had not found a better way.

This do not work wit -l ... but not sure if it is worthy of fixing this case

judovana · 2025-11-05T13:53:46Z

I would like to use

temurin-build/sbin/prepareWorkspace.sh

Line 592 in f4bcbeb

if bash ./configure --help | grep "with-png"; then

like approach, but in this moment, the sources do not exists. Thoughts?

judovana · 2025-11-12T15:43:17Z

The openjdk/jdk8u-dev#709 was integrated

karianna · 2025-11-13T19:39:49Z

sbin/build.sh

+    local majorBuildVersion=$(echo "${BUILD_CONFIG[TAG]}" | sed "s/jdk8u//" | sed "s/-.*//")
+    if [ 0${majorBuildVersion} -lt 482 ] ; then
+      echo "old"
+    elif [ 0${majorBuildVersion} -gt 482 ] ; then


Should this be gt and equal to?

Can we just simplify the logic here to capture 8u<version> and see if <version> is >=482 and then apply the freetype from source? There seems to be excess logic here

Should this be gt and equal to?

Nope. The "eq" is handled in final else. More readable it is:

if majorBuildVersion< 482 ; then //always old return "old" elif majorBuildVersion > 482] ; then //always new return "new" else // that means == decideByMinorBuildNumber() fi

Can we just simplify the logic here to capture 8u<version> and see if <version> is >=482 and then apply the freetype from source? There seems to be excess logic here

Of course we can. I made it to the most precise granularity, and if "b" is unimportant (which I Actually doubt) then of course. But it was done in early stage of 482, so maybe there can be done one exact match to 482-b01 and 482-b02 to avodi math check on b's XY.

I would like to use

temurin-build/sbin/prepareWorkspace.sh

Line 592 in f4bcbeb

if bash ./configure --help | grep "with-png"; then

like approach, but in this moment, the sources do not exists. Does anybody have any ideas? I will connect t some upcoming call due of this. @jiekang any idea who to ping/when to join a call?

@karianna Thanx for eyball, highly appreciated!

@judovana Is there a way to tell from the actual "source" what it is doing/supports? I don't know... but say if (some make file exists?!)

although not ideal, you could gate this logic on the existance or not of .github/workflows/freetype.vcxproj ,
which has been deleted as the submit workflow does not support building freetype src with this update?

hi! I would love to, But jdk sources do not exists in this moment. Otherwise check like

temurin-build/sbin/prepareWorkspace.sh

Line 592 in f4bcbeb

if bash ./configure --help | grep "with-png"; then

would always work, and would be much much better.

The only other way is to deference all this after jdk sources are built, which may not be trivial, as in "legacy" mode, the certificates are prepared long before jdk.

Tbh I would love to get rid of tag check, because the tag do not cover eg the build from tarball and maybe more.

I'm proposing to merge this, so jdk8 remain buildable, but would elaborate, on change of order.
That woudl mean to get rid of tag parsing, and try to reorder cloning the jdk, and building of cacerts. I already looked into it, and it seems doable. Only I got scared of such big change.
Or I will try to do so asap.

For reference (I see you changed to checking for the directory), the version is available in common/autoconf/version-numbers e.g. see openjdk/jdk8u@c0a36d8 You don't need to rely on Git metadata for this. Checking for what you actually want rather than a particular version is always preferable though, if possible.

That would require again to clone the repo, before all those checks. That was something I originally really wanted to avoid.

sbin/build.sh

Co-authored-by: Martijn Verburg <[email protected]>

judovana · 2025-11-17T10:55:28Z

@andrew-m-leonard @sxa thoughts please?

sxa

Noting that I have managed to build the 8u482-b02 version with the original build scripts (not from the temurin tags) without any problem so it's not necessarily clear (unless I made a mistake in my build) what error I should expect.

Noting also that if we change the version of freetype in the build the SBOM validation script will also need to be updated to match what gets produced.

andrew-m-leonard · 2025-11-21T15:00:10Z

fyi, jdk8u482-b02_adopt will be appearing shortly once i've resolved : adoptium/mirror-scripts#76

adamfarley · 2025-11-24T10:28:26Z

@sxa - Does removing/changing the "--with-freetype=/usr/local/" bit in solaris.sh fall under the scope of this PR?

https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-sparcv9-temurin-simple/120/console

configure: error: Valid values for --with-freetype are 'system' and 'bundled'

judovana · 2025-11-24T13:13:44Z

Noting that I have managed to build the 8u482-b02 version with the original build scripts (not from the temurin tags) without any problem so it's not necessarily clear (unless I made a mistake in my build) what error I should expect.

Hi @sxa thats exceptionally weird, it can not work via temurin scripts, unless you are setting up freetype manually, you will always get configure: error: Valid values for --with-freetype are 'system' and 'bundled' bbecause its reading had chnaged:

$$ cd ~/git/temurin-build/
$$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
$$ git status
On branch master
Your branch is up to date with 'origin/master'.
$$ git pull
remote: Enumerating objects: 4, done.
...
   a3adb91..c6c180f  noMoreFreeTypeFor8 -> origin/noMoreFreeTypeFor8
Already up to date.
$$ git log
commit 1159fa56119232e8588a174de80d51a1158d8691 (HEAD -> master, origin/master, origin/HEAD)
Author: Adam Farley <[email protected]>
Date:   Fri Oct 24 17:36:30 2025 +0100

    Update expected build gcc for linux platforms to 14.2.0 (#4283)
    
    Except for Alpine and risc, which stay the same.
    
    Signed-off-by: Adam Farley <[email protected]>
    
$$  sh  makejdk-any-platform.sh  --tag jdk8u482-b02  jdk8u
Starting makejdk-any-platform.sh to configure, build (Adoptium)OpenJDK binary
Parsing opt: --tag
...
checking for cups/ppd.h... yes
configure: error: Valid values for --with-freetype are 'system' and 'bundled'
No configurations found for /home/jvanek/git/temurin-build/workspace/build/src/! Please run configure to create a configuration.
Makefile:55: *** Cannot continue.  Stop.
OpenJDK make failed, archiving make failed logs
Archiving and compressing with pigz

real	0m0.001s
user	0m0.000s
sys	0m0.002s
Your archive was created as /home/jvanek/git/temurin-build/workspace/build/src/build/linux-x86_64-normal-server-release/OpenJDK.tar.gz
Moving the artifact to location /home/jvanek/git/temurin-build/workspace/target//OpenJDK-makefailurelogs.tar.gz
archive done.
Failed to make the JDK, exiting

After the fix:

$$ git checkout noMoreFreeTypeFor8
Switched to branch 'noMoreFreeTypeFor8'
Your branch is behind 'origin/noMoreFreeTypeFor8' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)
$$ git pull
Updating a3adb91..c6c180f
Fast-forward
 sbin/build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$$ git log
commit c6c180f6a015113395a03ee2a2878ccb20b484ef (HEAD -> noMoreFreeTypeFor8, origin/noMoreFreeTypeFor8)
Author: judovana <[email protected]>
Date:   Mon Nov 17 10:45:48 2025 +0100

    Update sbin/build.sh
    
    Co-authored-by: Martijn Verburg <[email protected]>

commit a3adb91b195deb0039c8f1555ac0400132af9465
Author: Jiri Vanek <[email protected]>
Date:   Thu Nov 13 11:57:56 2025 +0100

    The in-tree freetype will appear in 482-b02

$$  sh  makejdk-any-platform.sh  --tag jdk8u482-b02  jdk8u
Starting makejdk-any-platform.sh to configure, build (Adoptium)OpenJDK binary
Parsing opt: --tag
...
Using freetype: bundled
checking fontconfig/fontconfig.h usability... yes
...
## Starting langtools
Compiling 2 files for BUILD_TOOLS

judovana · 2025-11-24T13:15:47Z

@sxa - Does removing/changing the "--with-freetype=/usr/local/" bit in solaris.sh fall under the scope of this PR?

https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-sparcv9-temurin-simple/120/console
configure: error: Valid values for --with-freetype are 'system' and 'bundled'

Thats it. The patch is adjusting exactly this. Tahnx @adamfarley

judovana · 2025-11-24T13:30:15Z

Noting also that if we change the version of freetype in the build the SBOM validation script will also need to be updated to match what gets produced.

Thats a lot of EXPECTED_FREETYPE versions. In theory, once this effort is finished, all jdks (except 26) will have same, bundeld version. Isnt that correct?

judovana · 2025-11-24T15:41:36Z

Noting also that if we change the version of freetype in the build the SBOM validation script will also need to be updated to match what gets produced.

Thats a lot of EXPECTED_FREETYPE versions. In theory, once this effort is finished, all jdks (except 26) will have same, bundeld version. Isnt that correct?

I did some reading, and some experiments. Can I deffere this to separate PR?
How to test that file?

It do not seem correct to me. I thought, that everywhere except 8, the bundled freetype is used - that means, single version, as all jdks except tip (and for now 8) are on 2.13.3, no metter of OS. And jdk8 willb e on 2.9.0 now, 2.10.4 soon, and hopefully 2.13.3 before CPU...

judovana · 2025-11-24T17:29:01Z

@andrew-m-leonard

hi! I was partially wrong. Or better confused myself. Jdk exists in the moment of those checks, so I will switch to somehting like

isFreeTypeInSources() {
 if [ ! -e  build/src ] ; then
    echo "No jdk found to determine libfreetype/src presence"
    exit 1
 fi
 find build/src | grep  -q libfreetype/src
 return $?
}

That will simplify the whole code a lot. Howver, waht I want to do, and what made me to write that "jdk sources do nto exists in that moment" is this

 function configureWorkspace() {
   if [[ "${BUILD_CONFIG[ASSEMBLE_EXPLODED_IMAGE]}" != "true" ]]; then
     createWorkspace
+    checkoutAndCloneOpenJDKGitRepo
     downloadingRequiredDependencies
     downloadDevkit
     relocateToTmpIfNeeded
-    checkoutAndCloneOpenJDKGitRepo
     applyPatches
     if [ "${BUILD_CONFIG[CUSTOM_CACERTS]}" = "true" ] ; then
       prepareMozillaCacerts

Without it, the freetype would be downloaded, and build, but later not used. Thats why I moved to the cryptic tag parsing.

I will now elaborate on this, and will stop building and downloading (and of course using) the freetype if isFreeTypeInSources will be true.

andrew-m-leonard · 2025-11-27T12:04:02Z

The move to "bundled" I did back in 2023, was to support reproducible builds, so as to ensure deterministic freetype binary.

sxa · 2025-11-27T12:47:50Z

The move to "bundled" I did back in 2023, was to support reproducible builds, so as to ensure deterministic freetype binary.

Is there a particular reason that change wasn't done across all versions (even though they wouldn't have been reproducible)? That would have seemed the obvious thing to do which makes me nervous that there was some specific problem that was potentially going to be caused.

andrew-m-leonard · 2025-11-27T15:07:47Z

The move to "bundled" I did back in 2023, was to support reproducible builds, so as to ensure deterministic freetype binary.

Is there a particular reason that change wasn't done across all versions (even though they wouldn't have been reproducible)? That would have seemed the obvious thing to do which makes me nervous that there was some specific problem that was potentially going to be caused.

From the PMC minutes discussing this back in Nov 22nd 2023:
For reproducible and consistency purposes we would prefer to go with bundling the freetype library. If a user is used to using fonts provided by their system freetype they may notice a difference with this change
Plan to start with JDK21 on moving to bundled fontlib before rolling out to earlier versions.
Don’t expect to see problems with OpenJDK support of the latest version of fontlib.
Question if this lack of reproducibility is known upstream, and if the fontlib is bundled by default. If not this should be raised there too.
DECISION: PMC agreed to start bundling fontlib as part of the build from JDK21 immediately, then backporting to earlier JDK version builds if this is successful.

andrew-m-leonard · 2025-11-27T15:09:16Z

So the plan originally was to backport to earlier versions... but that was not done yet... So seems reasonable to do that now

judovana · 2025-11-27T15:19:33Z

Thanx a lot for all that insight. Highly appreciated!

judovana · 2025-11-28T15:22:24Z

hi! Did run quite a few tests around the freetype switches on both freetype bundled and external-needed jdks, and it seems it behave as it should now.

Ok t go by me ;)

Please, state your wish how to handle all related PRs: #4306 (comment)

I do not mind to include them in this, or as separate. Being separate have afaik many benefits, but it is up to you. W can even discuss them in separate PRs, and then move to this one. Maybe even some logic (liek the checks may move elsewhere (eg to the man/reasme one, but for that I'm more against, then for) . Note, that the configuration one, probably can not pass until this one is finished. Similarly the sbom one can not pass before 2.13.3 reaches jdk8u (already under review)

sxa · 2025-11-28T15:43:41Z

I do not mind to include them in this, or as separate. Being separate have afaik many benefits, but it is up to you.

I'm OK with the multi-PR approach :-) Thanks for all your work on this.

sbin/build.sh

sbin/prepareWorkspace.sh

Co-authored-by: Martijn Verburg <[email protected]>

setDefaultFreeType->setBundledFreeType setFreeTypeFromSrcs->setFreeTypeFromExternalSrcs

andrew-m-leonard · 2025-12-03T11:57:24Z

SBOM validation just needs fixing up now:

You should just need to fixup the values in here https://github.com/adoptium/temurin-build/blob/master/tooling/validateSBOMcontent.sh

andrew-m-leonard

SBOM validation fixup

judovana · 2025-12-04T08:46:36Z

SBOM validation fixup

Hi @andrew-m-leonard Sorry if ti caused any troubles, I made the sbom validation changes in different PR: #4315 (there is more related changes, see: #4287 (comment) and #4306 (comment))

As stated above, I can merge them all here, or do it separately. But seems like theirs nature is more close to splitting them up. especially as the ideal sbom change depends on version of freetype in jdk8 and on adoptium build configs

I may - maybe - to do some minimalistic chnage to sbom here, just for jdk8u482-b02 purposes, but it may lead jsut to more future work later. Also the sbom "if's" are so complex that I may simply miss the correct execution branch

* All build-configs should use default (bundeld) free type Since jdk8u482.b02 all maintained JDKs have in tree freetype. All jdks should use it unless there is necessary reason to do so. See #4287 (comment) * Aligned freetypeOnlyBundledOnCertainPlatforms to current state

* Narrowed description of freetype switeches See #4287 (comment) * On "old-jdk8" the docs man/readme lies - as using the --skip-freetype leads to use system freetype, the --freetype-dir is ignored (which is in ooposite to docs) * When --skip-freetype is omitted, the --freetype-dir works as expected. * On "new-jdk8" and on 11+the usage of -freetype-dir is leading to imminent configure error * with added --skip-freetype its useless as before, as system is used. * Improved grammar of freetype switches description Co-authored-by: Martijn Verburg <[email protected]> --------- Co-authored-by: Martijn Verburg <[email protected]>

* All build-configs should use default (bundeld) free type Since jdk8u482.b02 all maintained JDKs have in tree freetype. All jdks should use it unless there is necessary reason to do so. See adoptium#4287 (comment) * Aligned freetypeOnlyBundledOnCertainPlatforms to current state

* Initial minimalistic adaptation of 8 to build with in-tree freetype * Determining free type absed on jdk's 8 tag the if is to long, will refactor * Simplified the condition * The in-tree freetype will appear in 482-b02 * Update sbin/build.sh Co-authored-by: Martijn Verburg <[email protected]> * No longer building freetype if it exists in sources * Get rid of relative path * Aligned modified block to two spaces * Enforced the freetype switches checks * Update sbin/prepareWorkspace.sh Co-authored-by: Martijn Verburg <[email protected]> * Update sbin/prepareWorkspace.sh Co-authored-by: Martijn Verburg <[email protected]> * Update sbin/prepareWorkspace.sh Co-authored-by: Martijn Verburg <[email protected]> * Small rephrasing ow errors * Renamed main freetype methods to match theirs real meaning setDefaultFreeType->setBundledFreeType setFreeTypeFromSrcs->setFreeTypeFromExternalSrcs --------- Co-authored-by: Martijn Verburg <[email protected]>

* Narrowed description of freetype switeches See adoptium#4287 (comment) * On "old-jdk8" the docs man/readme lies - as using the --skip-freetype leads to use system freetype, the --freetype-dir is ignored (which is in ooposite to docs) * When --skip-freetype is omitted, the --freetype-dir works as expected. * On "new-jdk8" and on 11+the usage of -freetype-dir is leading to imminent configure error * with added --skip-freetype its useless as before, as system is used. * Improved grammar of freetype switches description Co-authored-by: Martijn Verburg <[email protected]> --------- Co-authored-by: Martijn Verburg <[email protected]>

Initial minimalistic adaptation of 8 to build with in-tree freetype

ac5ed0a

judovana mentioned this pull request Oct 28, 2025

8193017: Import freetype sources into OpenJDK source tree openjdk/jdk8u-dev#709

Closed

4 tasks

judovana changed the title ~~Initial minimalistic adaptation of 8 to build with in-tree freetype~~ Initial minimalistic adaptation of JDK-8 to build with in-tree freetype Oct 28, 2025

Determining free type absed on jdk's 8 tag

aecbf09

the if is to long, will refactor

judovana force-pushed the noMoreFreeTypeFor8 branch from db1626c to 09d18b8 Compare November 5, 2025 13:35

Simplified the condition

ee63d39

judovana force-pushed the noMoreFreeTypeFor8 branch from 09d18b8 to ee63d39 Compare November 5, 2025 13:52

The in-tree freetype will appear in 482-b02

a3adb91

karianna requested changes Nov 13, 2025

View reviewed changes

karianna requested changes Nov 17, 2025

View reviewed changes

sbin/build.sh Outdated Show resolved Hide resolved

Update sbin/build.sh

c6c180f

Co-authored-by: Martijn Verburg <[email protected]>

judovana mentioned this pull request Nov 19, 2025

jdk8 uses bundled freetype since jdk8u482-b02 #4306

Closed

sxa reviewed Nov 21, 2025

View reviewed changes

sxa mentioned this pull request Nov 21, 2025

jdk8u482-b02 has not had an _adopt tag created. adoptium/mirror-scripts#76

Closed

adamfarley mentioned this pull request Nov 24, 2025

Build Issue Summary for 2025-11-24 #4312

Closed

judovana force-pushed the noMoreFreeTypeFor8 branch from 3c67327 to a0836d8 Compare November 28, 2025 15:11

Enforced the freetype switches checks

24726ac

judovana force-pushed the noMoreFreeTypeFor8 branch from a0836d8 to 24726ac Compare November 28, 2025 15:14

karianna requested changes Dec 1, 2025

View reviewed changes

judovana and others added 5 commits December 2, 2025 09:37

Update sbin/prepareWorkspace.sh

4118151

Co-authored-by: Martijn Verburg <[email protected]>

Update sbin/prepareWorkspace.sh

1e5b35f

Co-authored-by: Martijn Verburg <[email protected]>

Update sbin/prepareWorkspace.sh

edc13fd

Co-authored-by: Martijn Verburg <[email protected]>

Small rephrasing ow errors

5e63e97

Renamed main freetype methods to match theirs real meaning

ce4a1fb

setDefaultFreeType->setBundledFreeType setFreeTypeFromSrcs->setFreeTypeFromExternalSrcs

judovana requested a review from karianna December 3, 2025 11:13

andrew-m-leonard requested changes Dec 3, 2025

View reviewed changes

karianna approved these changes Dec 3, 2025

View reviewed changes

judovana requested review from andrew-m-leonard and sxa December 4, 2025 19:38

andrew-m-leonard approved these changes Dec 5, 2025

View reviewed changes

adamfarley merged commit 9a8b11b into adoptium:master Dec 5, 2025
29 checks passed

Uh oh!

adaptation of JDK-8 to build with in-tree freetype #4287

adaptation of JDK-8 to build with in-tree freetype #4287

Uh oh!

Conversation

judovana commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

karianna commented Oct 28, 2025

Uh oh!

judovana commented Oct 29, 2025

Uh oh!

karianna commented Oct 29, 2025

Uh oh!

judovana commented Oct 30, 2025

Uh oh!

judovana commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

judovana commented Nov 5, 2025

Uh oh!

judovana commented Nov 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

judovana Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

judovana commented Nov 17, 2025

Uh oh!

sxa left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrew-m-leonard commented Nov 21, 2025

Uh oh!

adamfarley commented Nov 24, 2025

Uh oh!

judovana commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

judovana commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

judovana commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

judovana commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

judovana commented Nov 24, 2025

Uh oh!

andrew-m-leonard commented Nov 27, 2025

Uh oh!

sxa commented Nov 27, 2025

Uh oh!

andrew-m-leonard commented Nov 27, 2025

Uh oh!

andrew-m-leonard commented Nov 27, 2025

Uh oh!

judovana commented Nov 27, 2025

Uh oh!

judovana commented Oct 28, 2025 •

edited

Loading

judovana commented Nov 5, 2025 •

edited

Loading

judovana Dec 5, 2025 •

edited

Loading

sxa left a comment •

edited

Loading

judovana commented Nov 24, 2025 •

edited

Loading

judovana commented Nov 24, 2025 •

edited

Loading

judovana commented Nov 24, 2025 •

edited

Loading

judovana commented Nov 24, 2025 •

edited

Loading

judovana commented Dec 4, 2025 •

edited

Loading